💬 2단계 — 내 예약 목록 조회 (쿼리 메서드 / N+1 / fetch join vs @EntityGraph)

들어가기 전 자기 진단

Q. 메서드 이름 쿼리 vs JPQL 중 무엇이 먼저 떠오르나? 근거는?

현재 테이블은 member 없이 이름만 보유하지만, name이 Member 엔티티로 승격되면 조인이 필요하다. 한 사람이 여러 예약을 가지므로 예약 N : 사람 1 구조가 된다.

Q. 메서드 이름 쿼리·JPQL 중 어느 것을 썼나?

단계별로 옮겨가며 풀었다.

1) LazyInitializationException

• 컨트롤러(트랜잭션 밖)에서 DTO 변환 중 member.getName() 등 LAZY 접근 → 세션 닫힌 상태라 프록시 초기화 실패.
  2) N+1 발견
• open-in-view=false를 주석 처리(OSIV 켬)해 LazyInit은 회피했으나, 로그상 예약 건마다 member/slot/slot.theme/slot.time을 개별 SELECT → N배 폭증.
  3) 해결 — fetch join 검증 후 @EntityGraph 채택
• fetch join(JPQL)으로 JOIN 한 방에 가져오면 LazyInit·N+1이 동시 해결됨을 확인.
• 조건이 member.id 하나로 단순 → 최종은 메서드 이름 쿼리 + @EntityGraph로 정리.
• 해결 후 open-in-view=false 복구(다시 끔). OSIV는 문제를 가릴 뿐, 연관 즉시 로딩이 진짜 해결.
  검증에 쓴 fetch join:

@Query("select r from Reservation r " +
       "join fetch r.member join fetch r.slot s " +
       "join fetch s.theme join fetch s.time " +
       "where r.member.id = :memberId")
List<Reservation> findMineWithDetails(@Param("memberId") Long memberId);

해결 후 로그 — JOIN 한 방으로 합쳐짐:

select r1_0.id, ..., m1_0.id, m1_0.name, ..., t1_0.*, t2_0.*
from reservation r1_0
join member m1_0 on m1_0.id = r1_0.member_id
join slot s1_0 on s1_0.id = r1_0.slot_id
join theme t1_0 on t1_0.id = s1_0.theme_id
join reservation_time t2_0 on t2_0.id = s1_0.time_id
where m1_0.id = ?

최종 채택 — @EntityGraph

@EntityGraph(attributePaths = {"member", "slot", "slot.theme", "slot.time"})
List<Reservation> findByMemberId(Long memberId);

경로 표기: member/slot은 Reservation 직속 필드 → 그냥 이름. slot.theme/slot.time은 Slot에 있어 slot을 거쳐야 닿음 → 경로로.

fetch join과 차이: 메서드 이름 쿼리에 얹을 수 있고(fetch join은 JPQL 필요), 쿼리·성능은 사실상 동일.

조인 INNER/LEFT 규칙 (그래프 관찰):

• optional=false(NOT NULL)면 Hibernate가 INNER로 최적화 → 로그에 join(현재 전부 optional=false).
• 규칙①: 같은 깊이 연관은 각자 optional로 결정(형제 독립).
• 규칙②: 부모가 LEFT면 자식도 LEFT 전파(slot이 LEFT면 slot.theme도 LEFT).
• @EntityGraph는 optional 보고 자동, join fetch는 무조건 INNER(LEFT는 left join fetch).
  선택 이유: 조건이 단순(member.id 하나)이라 메서드 이름 쿼리로 충분. 연관 로딩만 어노테이션 한 줄로 분리 → 쿼리 깔끔. optional=false라 그래프여도 INNER로 나가 fetch join과 결과·성능 동일.

Q. 그 결정의 한계는?

현재 기준: member/slot/theme/time 모두 @ManyToOne(단일)이라 행이 안 늘어 페이징·컬렉션 다중은 해당 없음.

핵심: 단순 조회는 @EntityGraph, 복잡한 조건은 fetch join. 정교한 쿼리(일부 컬럼·집계·연관별 조건)는 DTO 조회/QueryDSL로.

💬 3단계 — 예약 대기 기능 (도메인 설계 판단 / JPQL 본격)

들어가기 전 자기 진단

Q. 예약 대기를 별도 엔티티로 만들지, Reservation에 status 컬럼만 추가할지? 첫 직감과 근거는?

첫 직감 — status 컬럼 (선택 A)

@Entity
public class Reservation {
    @Enumerated(EnumType.STRING)
    private Status status;   // APPROVED, WAITING
}

근거: 대기와 확정은 본질적으로 같은 "예약 행위"이고 승인 여부만 다르다. 대기 승인은 WAITING → APPROVED로 상태만 바꾸면 되니, 별도 엔티티로 데이터를 옮기는 것보다 자연스럽다.

분리(선택 B)도 고려 — 트레이드오프

판단 기준 = 전환 빈도: 방탈출은 대기→확정 전환이 잦음(취소 시 자동 승격). 분리하면 전환마다 데이터 이사 → 부담. status는 changeStatus() 값 하나로 끝. → 분리의 null 안전성보다 잦은 전환 비용이 커 status 선택.

겪은 한계 — status null 문제: 생성 시 status 안 채우면 null 가능. 영속화 전엔 보장 약함.
→ 해결은 분리가 아니라 생성 강제: create()에서 status 항상 세팅 + DB not null 제약. "유효하지 않은 객체를 못 만들게" 막으면 null 사라지고 status 장점 유지.

상태 패턴은? 상태 2개(대기/확정)뿐이라 enum으로 충분. 상태 패턴은 상태가 여럿이고 전이가 복잡할 때. 현재는 과함.

3-1. N+1과 fetch join 비교 (관찰 과제 2)

GET /reservations-mine에서 예약 N + 대기 M을 가져와 DTO 변환 시:

• 변환 전(N+1): 항목마다 getTheme().getName()·getTime().getStartAt() 접근 → 개별 SELECT가 항목 수만큼 폭증.
• fetch join/@EntityGraph 적용 후: JOIN 한 방으로 합쳐져 쿼리 1개.
• row 중복: 단일 연관(@manytoone)만 fetch라 행 안 늘어남(중복 없음).

2단계 회고에 before/after 로그를 나란히 기록함.

3-2. JPQL 본격 — N번째 대기 계산

메서드 이름 쿼리로 못 풂 → JPQL + 서브쿼리 + CASE WHEN.

@Query("""
    SELECT r.id,
        CASE WHEN r.status = ...APPROVED THEN 0L
             ELSE (SELECT COUNT(w) + 1L FROM Reservation w
                   WHERE w.slot = r.slot
                     AND w.status = ...WAITING
                     AND w.createdAt < r.createdAt)
        END
    FROM Reservation r WHERE r.member.id = :memberId
    """)

Q. JPQL이 발행하는 SQL

select r1_0.id,
    case when r1_0.status='APPROVED' then 0
         else (select (count(r2_0.id)+1) from reservation r2_0
               where r2_0.slot_id=r1_0.slot_id
                 and r2_0.status='WAITING'
                 and r2_0.created_at<r1_0.created_at)
    end
from reservation r1_0
where r1_0.member_id=?

Q. 메서드 이름 쿼리로는 왜 못 푸나? (1줄)

메서드 이름 쿼리는 단순 조건 조합만 표현할 수 있어, CASE WHEN·서브쿼리·집계 같은 연산은 애초에 표현이 불가능하기 때문이다.

참고: 결과를 Object[]로 받아 가공 중 → DTO 생성자 표현식(SELECT new ...Rank(...))으로 바꾸면 캐스팅 없이 타입 안전. (개선 여지)

💬 4단계 — 예약 대기 관리 + 자동 승인 (트랜잭션 경계 / 동시성 / flush 순서)

들어가기 전 자기 진단

Q. 자동 승인 로직을 어디에 둘 것인가? 첫 직감과 근거는?

자동 승인은 데이터 정합성 문제다. 취소/수정 후 자동 승인이 제대로 반영 안 되면 "승인이 비어버린 예약"이 생길 수 있다. 그러니 통째로 하나의 비즈니스 로직(=하나의 트랜잭션)으로 묶어야 한다.

Q. 트랜잭션 경계는 어디까지 굳혀야 하나?

트랜잭션은 원자성이 필요한 범위까지 묶는다 — 하나라도 실패하면 전부 롤백돼야 하는 작업들까지. 데이터 정합성이 걸린 건(상태 전이) 묶고, 되돌릴 필요 없는 건(알림·로그·외부 호출) 트랜잭션 밖으로 뺀다. 트랜잭션은 짧게 유지.

Q. 자동 승인 로직의 위치는?

수정·삭제에서 변경(취소 등)이 일어나면, 같은 흐름에서 자동 승인이 일어난다. (별도 이벤트로 분리하지 않고 Service 메서드 내 처리)

보충: 이벤트로 뺄 수도 있으나(동기 이벤트면 같은 트랜잭션 유지 가능), 할 일이 자동 승인 하나뿐이고 취소와 밀접하므로 메서드 분리가 가장 단순. 이벤트는 할 일이 여러 개로 늘고 모듈이 갈릴 때 유효.

본질 신호 점검

① 트랜잭션 경계 — 한 메서드 vs 분리

• 한 메서드(@transactional) 안에서 둘 다 처리.
• 취소와 자동 승인이 동시에 성공/실패해야 한다(원자성). 하나만 반영되면 "취소는 됐는데 다음 대기자 승인 안 된" 불일치.
  ② 동시성 — 같은 자리 동시 취소·승인
• 트랜잭션은 그 사이 다른 트랜잭션이 같은 값을 바꾸는 것을 고려하지 않음 → race condition 가능.
• 두 사용자가 동시에 같은 슬롯 처리 → 둘 다 "빈자리"로 읽고 둘 다 승인 → 한 자리 2명.
• H2라서 부분 유니크 제약("status=APPROVED일 때만 slot_id 유니크")을 걸기 어려워 더 취약.
• 해결 방향: 자동 승인 로직 앞에서 슬롯에 비관적 락(@Lock(PESSIMISTIC_WRITE))을 걸어, 같은 슬롯을 처리하려는 트랜잭션들을 슬롯 락 앞에서 순차화. (FK가 락을 전파하는 게 아니라, 슬롯 행을 먼저 잠가 순서를 만드는 것.)
  ③ flush 순서 — Reservation/Waiting 두 도메인 함께 변경 시
• flush는 호출 순이 아니라 타입별 순서: INSERT → UPDATE → 컬렉션 삭제 → 컬렉션 추가/수정 → DELETE.
• "삭제 후 생성/수정" 순서가 필요하면 중간에 em.flush()로 DELETE를 먼저 강제.
• flush와 트랜잭션: 상관없다. flush는 SQL을 DB에 전송할 뿐, 커밋 전까진 확정 아님. 중간 실패 시 flush한 것까지 전부 롤백 → 정합성 영향 없음.

단, 현재는 status 단일 엔티티라 자동 승인이 UPDATE 하나뿐 → INSERT/DELETE가 없어 flush 순서 문제를 실제로 만나지 않음. (별도 Waiting 엔티티였다면 만났을 신호.)

Q. 그 결정의 한계 — 트랜잭션 경계·동시성·일관성 중 가장 약한 것은?

동시성이 가장 약하다.

• 두 사용자가 동시에 같은 슬롯 처리 시 둘 다 승인되는 race condition.
• H2 부분 유니크 제약 한계로 DB 레벨 방어도 어려움.
• → 비관적 락(슬롯 행 락)으로 순차화하는 것이 보완책.
  한 줄: 단일 트랜잭션의 원자성·일관성은 확보했으나, 트랜잭션 간 동시성이 가장 약하다. 같은 슬롯 동시 처리 시 race condition이 남아 있고, 비관적 락으로 보완해야 한다.

동시성 보완 — 락 선택 (참고)

자동 승인은 "한 자리 2명"이 치명적이라 확실한 순차 처리 필요 → 슬롯 비관적 락이 적합.